feat(permissions): add a command to reconcile the groups with their f… - #268

…ixture

The permissions of the roles live in ngen/fixtures/group.json, but that
fixture is only loaded on a brand new installation: loaddatafirsttime skips
everything when the user table is not empty. So when a release adds a
permission to a role, a new model or a view_ that was missing, the
installations already running never get it.

The two ways out were both bad. 'loaddata group' replaces the permissions of
every group with the ones of the fixture, so it silently drops whatever an
administrator granted or revoked. A data migration would rewrite decisions
that belong to the operator, unattended, on upgrade.

syncgroups is explicit and additive: it grants the permissions of the fixture
the group does not have, creates the groups the fixture defines and the
installation does not, and touches nothing else. --prune opts into removing
what the fixture does not define, --dry-run reports without applying,
--check exits with an error if there is anything pending, for CI, and
--group limits it to one role.

It also reports the roles holding add, change or delete on a model without
its view. DRF maps GET to view_<model>, so those permissions cannot be used
through the api at all: it is how the Incident Responder role ended up unable
to read the playbooks it is meant to run.

Review of the branch:

- Creating a group counts as a change. It was only counting the permissions
  it granted, so a group the fixture defines with none would be created while
  the command reported everything in sync, and --check would pass.
- The report of write permissions without their view is skipped on a dry run
  with pending changes: it would list the very permissions that applying
  those changes may make usable.
- The permissions of the fixture are resolved against a single query instead
  of one per entry. The shipped fixture holds 544 of them, so the command
  went from 546 queries to 17.